Virtual network interface for relayed nat traversal

ABSTRACT

By providing a virtual network interface ( 1140 ) to a platform or an operating system wide implementation of the STUN protocol and its TURN extension, the invention allows applications ( 1110, 1120, 1130 ) located in a private network behind a NAT to communicate with their respective peers ( 1321, 1322, 1323 ) using sockets as usual while still getting the full benefit of the STUN protocol and its TURN extension for NAT traversal purposes.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to telecommunications. In particular, thepresent invention relates to Network Address Translator traversal usinga relay.

2. Description of the Related Art

Network Address Translation (NAT) is a computer networking technique oftransmitting and receiving network traffic through a router thatinvolves rewriting the source and/or destination IP (Internet protocol)addresses and typically also the TCP/UDP (Transmission ControlProtocol/User Datagram Protocol) port numbers of data packets as theypass through. Typically Network Address Translation is used to enablemultiple hosts on a private network to access the Internet using asingle public IP address.

Network Address Translation has its drawbacks, however. For example, itbreaks many existing IP applications and makes it difficult to deploynew ones. Examples of such affected protocols include many peer-to-peerprotocols, such as multimedia communications protocols (e.g. Voice overIP or VoIP) and file sharing protocols.

STUN (Session Traversal Utilities for Network Address Translation;previously also known as Simple Traversal Underneath Network AddressTranslators, as well as Simple Traversal of User Datagram ProtocolThrough Network Address Translators) is a network protocol developed toaddress some of the issues related to Network Address Translation. STUNallows a client behind a Network Address Translator(s) to find out itspublic address (or its reflexive transport address), the type of NetworkAddress Translator it is behind, and the internet-side port associatedby the Network Address Translator with a particular local port.Typically, this information is then used to set up e.g. UDPcommunication between two hosts of which one or both are behind NetworkAddress Translator routers.

However, this reflexive transport address can be used by the client forreceiving packets from peers only when the client is behind “good” NATs.In particular, if a client is behind a NAT whose mapping behavior isaddress or address and port dependent, the reflexive transport addresswill not be usable for communicating with a peer.

To address this problem, an extension to STUN protocol called TURN(Traversal Using Relays around NAT) has been developed. A TURN serveracts as a relay that sits on the public side of a NAT, and allocatestransport addresses to clients reaching it from behind the private sideof the NAT. These allocated addresses are from interfaces on the relay(i.e. TURN server). When the relay receives a packet on one of theseallocated addresses, the relay forwards it toward the client.

While STUN in combination with its extension TURN does provide a workingsolution to NAT traversal, presently a client portion of the STUNprotocol with its TURN extension is typically implemented directly ineach application (such as e.g. VoIP client application) requiring itsservices.

Yet, today there are often multiple applications provided in a singledevice (such as e.g. a communications terminal device) each of whichrequires services of the STUN protocol and its TURN extension. It wouldbe useful to implement the STUN protocol and its TURN extension to aplatform or an operating system as a service that can simultaneously beused by multiple applications.

At the same time, if the STUN protocol and its TURN extension wereimplemented as a service provided by a platform, it would be beneficialif applications needed minimal changes to utilize the STUN protocol andits TURN extension. Since various applications involved in packetswitched data communications typically utilize sockets, it would bebeneficial if these applications could communicate with their respectivepeers using sockets as usual while still getting the full benefit of theSTUN protocol and its TURN extension for NAT traversal purposes.

SUMMARY OF THE INVENTION

A first aspect of the present invention is a method in which, inresponse to at least one socket being bound to a relayed transportaddress by at least one application, socket calls made by the at leastone application to the bound socket are intercepted, each interceptedsocket call is replaced with a predetermined network address translatortraversal protocol message, and the network address translator traversalprotocol messages are forwarded to a network address translatortraversal server. The relayed transport address has been assigned by thenetwork address translator traversal server for data packet relay use bythe at least one application behind the network address translator. Inresponse to at least one network address translator traversal protocolmessage being sent from the network address translator traversal serverto the at least one application, the sent at least one network addresstranslator traversal protocol message is intercepted, data in theintercepted at least one network address translator traversal protocolmessage is analyzed, and the data is forwarded to the at least onesocket bound to the relayed transport address based on the analysis.

A second aspect of the present invention is an apparatus which comprisesa first interceptor that is configured to intercept, in response to atleast one socket being bound to a relayed transport address by at leastone application behind a network address translator, socket calls madeby the at least one application to the bound socket, replace eachintercepted socket call with a predetermined network address translatortraversal protocol message, and forward the network address translatortraversal protocol messages to a network address translator traversalserver, the relayed transport address having been assigned by thenetwork address translator traversal server for data packet relay use bythe at least one application behind the network address translator. Theapparatus of the second aspect further comprises a second interceptorthat is configured to, in response to at least one network addresstranslator traversal protocol message being sent from the networkaddress translator traversal server to the at least one application,intercept the sent at least one network address translator traversalprotocol message, analyze data in the intercepted at least one networkaddress translator traversal protocol message, and forward the data tothe at least one socket bound to the relayed transport address based onthe analysis.

A third aspect of the present invention is a computer program embodiedon a computer readable medium, the computer program controlling adata-processing device to perform:

in response to at least one socket being bound to a relayed transportaddress by at least one application, intercepting socket calls made bythe at least one application to the bound socket, replacing eachintercepted socket call with a predetermined network address translatortraversal protocol message, and forwarding the network addresstranslator traversal protocol messages to a network address translatortraversal server, the relayed transport address having been assigned bythe network address translator traversal server for data packet relayuse by the at least one application behind the network addresstranslator; and

in response to at least one network address translator traversalprotocol message being sent from the network address translatortraversal server to the at least one application, intercepting the sentat least one network address translator traversal protocol message,analyzing data in the intercepted at least one network addresstranslator traversal protocol message, and forwarding the data to the atleast one socket bound to the relayed transport address based on theanalysis.

A fourth aspect of the present invention is an apparatus which comprisesa first intercepting means for, in response to at least one socket beingbound to a relayed transport address by at least one application behinda network address translator, intercepting socket calls made by the atleast one application to the bound socket, replacing each interceptedsocket call with a predetermined network address translator traversalprotocol message, and forwarding the network address translatortraversal protocol messages to a network address translator traversalserver, the relayed transport address having been assigned by thenetwork address translator traversal server for data packet relay use bythe at least one application behind the network address translator. Theapparatus of the fourth aspect further comprises a second interceptingmeans for, in response to at least one network address translatortraversal protocol message being sent from the network addresstranslator traversal server to the at least one application,intercepting the sent at least one network address translator traversalprotocol message, analyzing data in the intercepted at least one networkaddress translator traversal protocol message, and forwarding the datato the at least one socket bound to the relayed transport address basedon the analysis.

In an embodiment of the invention, the network address translatortraversal protocol comprises a Session Traversal Utilities for NetworkAddress Translation (STUN)-protocol provided with Traversal Using Relaysaround Network Address Translation (TURN)-extension.

In an embodiment of the invention, at least one intercepted socket callcomprises a socket call connect( ), and wherein the replacingpredetermined network address translator traversal protocol messagecomprises a Connect Request-message.

In an embodiment of the invention, at least one intercepted socket callcomprises a socket call connect( ), and wherein the replacingpredetermined network address translator traversal protocol messagecomprises a Set Active Destination Request-message.

In an embodiment of the invention, at least one intercepted socket callcomprises a socket call send( ), and wherein the replacing predeterminednetwork address translator traversal protocol message comprises a SendIndication-message.

In an embodiment of the invention, at least one intercepted socket callcomprises a socket call recv( ), and wherein the replacing predeterminednetwork address translator traversal protocol message comprises a DataIndication-message.

In an embodiment of the invention, the at least one socket bound to therelayed transport address comprises one of a datagram socket and astream socket.

In an embodiment of the invention, the assigned relayed transportaddress comprises multiple ports, each for binding to one socket.

It is to be understood that the aspects and embodiments of the inventiondescribed above may be used in any combination with each other. Severalof the aspects and embodiments may be combined together to form afurther embodiment of the invention. A method, an apparatus, a system ora computer program which is an aspect of the invention may comprise atleast one of the embodiments of the invention described above.

The invention allows applications located in a private network behind aNAT to communicate with their respective peers using sockets as usualwhile still getting the full benefit of the STUN protocol and its TURNextension for NAT traversal purposes. The invention allows theseapplications to utilize the STUN protocol and its TURN extension withminimal or no changes to the applications themselves since no clientportion of the STUN protocol or its TURN extension need to beimplemented in the applications. Rather, the invention provides avirtual network interface to a platform or operating system wideimplementation of the STUN protocol and its TURN extension that enablesthe applications to communicate with their respective peers usingsockets as usual.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a furtherunderstanding of the invention and constitute a part of thisspecification, illustrate embodiments of the invention and together withthe description help to explain the principles of the invention. In thedrawings:

FIG. 1 is a block diagram illustrating an apparatus according to anembodiment of the present invention, and

FIGS. 2 a-2 b are a signaling diagram illustrating a method according toan embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Reference will now be made in detail to the embodiments of the presentinvention, examples of which are illustrated in the accompanyingdrawings.

FIG. 1 is a block diagram illustrating an apparatus according to anembodiment of the invention. Terminal device 1100 is arranged in aprivate network 1000 (e.g. a Local Area network or a LAN). The privatenetwork 1000 is connected to public Internet 1300 via a Network AddressTranslator 1200. The private network 1000 is “private” in the sense thatits designated address (e.g. Internet Protocol or IP address) space isin use only inside the private network 1000. The Network AddressTranslator 1200 has a private address in the private address space ofthe private network 1000, and the Network Address Translator 1200further has at least one public address in the public address space ofthe Internet 1300. As traffic passes from the private network 1000 tothe Internet 1300, the source address in each packet is translated onthe fly from the private addresses to the public address. The NetworkAddress Translator 1200 tracks such data about each active connection asthe destination address and port. When a reply returns from the Internet1300 to the Network Address Translator 1200, it uses the connectiontracking data it stored during the outbound phase to determine where onthe private network 1000 to forward the reply. To an application or asystem on the Internet 1300, the Network Address Translator 1200 itselfappears to be the source/destination for this traffic.

A TURN server 1310 is arranged in the Internet 1300. Implementingappropriate portions of STUN (Session Traversal Utilities for NetworkAddress Translation) protocol together with its extension TURN(Traversal Using Relays around NAT), the TURN server 1310 acts as arelay that sits on the public side of the NAT 1200, and allocatestransport addresses to applications 1110, 1120, 1130 reaching it frombehind the private side of the NAT 1200. These allocated addresses (alsoknown as relayed transport addresses) are from interfaces on the relayor TURN server 1310. When the TURN server 1310 receives a packet fromthe Internet (e.g. from one of peer applications 1321, 1322, 1323) onone of these allocated addresses, the TURN server 1310 forwards ittowards the appropriate application 1110, 1120, or 1130. Thus, NATtraversal is enabled in the arrangement illustrated in FIG. 1. It is tobe understood that the TURN server 1310 does not need to a separateserver. Rather, the functionality of the TURN server 1310 may beimplemented in a suitable network element in the Internet 1300 that mayhave other functions also.

The applications 1110, 1120, 1130 and peer applications 1321, 1322, 1323may be e.g. Voice over Internet Protocol (VoIP) applications or otherpeer-to-peer applications. The terminal 1100 may be e.g. a smart phone,a personal digital assistant (PDA), or a laptop computer. It is to beunderstood that there may be multiple terminals in the private network1000 even though only one is illustrated in FIG. 1 for the sake ofclarity, and each of these multiple terminals may comprise multipleapplications communicating with peer applications in the Internet 1300.

In an embodiment of the invention, at least one of the applications1110, 1120, 1130 is configured to trigger and/or perform thedetermination or obtaining of a relayed transport address assigned bythe network address translator traversal server (i.e. the TURN server1310 in the embodiment of the invention illustrated in FIG. 1) for datapacket relay use by at least one of the applications 1110, 1120, 1130behind the Network Address Translator 1200 (i.e. in the private network1000). In another embodiment of the invention, the relayed transportaddress determination or obtaining may be triggered and/or performede.g. by an operating system (not illustrated in FIG. 1) of the terminal1100. In yet another embodiment of the invention, the relayed transportaddress determination or obtaining may be triggered and/or performede.g. by a virtual network interface 1140 of the invention.

For example, in an embodiment, the application 1110, 1120 or 1130 mightrequest setup of the relayed transport address from the operating systemof the terminal 1100 that would then get the relayed transport addressfrom the TURN server. Furthermore, in accordance with the invention, theoperating system of the terminal 1100 would then instantiate the virtualnetwork interface 1140 of the invention.

In another embodiment, the relayed transport address determination orobtaining may be triggered and/or performed by an appropriatemiddleware—e.g. by a component that implements ICE (InteractiveConnectivity Establishment) protocol—in response to a relayed transportaddress being required for peer-to-peer connection, for example. In thiscase, the application 1110, 1120 or 1130 may e.g. request a peer-to-peersocket connection from the middleware ICE-component which may then getthe relayed transport address from the TURN server and instantiate thevirtual network interface 1140 of the invention.

In accordance with an embodiment of the invention, the virtual networkinterface 1140 is arranged in the terminal 1100. In an embodiment, thevirtual network interface 1140 may be implemented as software, e.g. as apart of the operating system of the terminal 1100. For example, thevirtual network interface 1140 may be implemented e.g. as a serviceprovided by the operating system of the terminal 1100. In case of therebeing multiple terminals in the private network 1000, the virtualnetwork interface 1140 may be implemented in each of these multipleterminals.

Further in accordance with the above embodiment of the invention, thevirtual network interface 1140 further comprises a first interceptor1141 that is configured to intercept, in response to at least one of theapplications 1110, 1120, 1130 binding at least one socket to the relayedtransport address, socket calls made by the at least one application1110, 1120, 1130 to the bound socket. The first interceptor 1141 isfurther configured to replace each intercepted socket call with apredetermined network address translator traversal protocol message(e.g. a TURN message). The first interceptor 1141 is further configuredto forward these network address translator traversal protocol messagesto the TURN server 1310.

Further in accordance with the above embodiment of the invention, thevirtual network interface 1140 further comprises a second interceptor1142 that is configured to, in response to at least one network addresstranslator traversal protocol message (e.g. a TURN message) being sentfrom the TURN server 1310 to at least one of the applications 1110,1120, 1130, intercept the sent at least one network address translatortraversal protocol message. The second interceptor 1142 is furtherconfigured to analyze data in the intercepted at least one networkaddress translator traversal protocol message. The second interceptor1142 is further configured to forward the data to the at least onesocket bound to the relayed transport address based on the analysis.

FIGS. 2 a-2 b show a flow diagram illustrating a method according to anembodiment of the invention.

FIG. 2 a is a flow diagram illustrating a method according to anembodiment of the invention. The first application 1110, the virtualnetwork interface 1140, the network address translator 1200, the TURNserver 1310 and the first peer application 1321 of FIG. 1 are alsoillustrated in FIGS. 2 a-2 b. The first application 1110 and the firstpeer application 1321 may be e.g. Voice over Internet Protocol (VoIP)applications. In the embodiment of the invention illustrated in FIGS. 2a-2 b, the Internet Protocol (IP) address of the terminal 1100 (depictedin FIG. 1), and consequently that of the first application 1110, is10.0.1.1. As described above, this is a private address, i.e. it canonly be used inside the private network 1000. Further in the embodimentof the invention illustrated in FIGS. 2 a-2 b, the public IP address ofthe network address translator 1200 is 192.0.2.1. The TURN server 1310is listening for TURN requests on IP address 192.0.2.3 at port 8776.Further in the embodiment of the invention illustrated in FIGS. 2 a-2 b,the IP address of the first peer application 1321 is 192.0.2.17 and ituses port 12734 for VoIP.

At first, a relayed transport address is obtained from the TURN server1310 at steps 201-204. The steps 201-204 are a simplified example of howto obtain the relayed transport address, since the details of thisprocess are not relevant to the present invention.

At step, 201, a TURN protocol message ‘Allocate Request’ is sent fromthe first application 1110 towards the TURN server 1310. Thus, thesource address of the ‘Allocate Request’ is 10.0.1.1:4334 (the firstapplication 1110 having been allocating port 4334 on the interface ofthe terminal 1100 for its traffic in the present example), and thedestination address of the ‘Allocate Request’ is 192.0.2.3:8776. The‘Allocate Request’ arrives at the network address translator 1200 whichreplaces the source address to 192.0.2.1:63346 (and creates a mappingfrom 192.0.2.1:63346 to 10.0.1.1:4334 for later use). Then, the networkaddress translator 1200 forwards the ‘Allocate Request’ to the TURNserver 1310, step 202. In response to the received ‘Allocate Request’,the TURN server 1310 allocates 192.0.2.3:32766 as the relayed transportaddress. At step 203, the TURN server 1310 sends a TURN protocol message‘Allocate Response’ containing the relayed transport address192.0.2.3:32766. The source address of the ‘Allocate Response’ is192.0.2.3:8776, and the destination address of the ‘Allocate Response’is 192.0.2.1:63346, i.e. the ‘Allocate Response’ is sent to the networkaddress translator 1200 which then forwards the ‘Allocate Response’ tothe first application 1110 at address 10.0.1.1:4334 based on the mappingthe network address translator 1200 created earlier. As a result, arelayed transport address 192.0.2.3:32766 has now been obtained for useby the first application 1110 (as well as by the applications 1120 and1130).

At step 205, the first application 1110 binds a socket to the relayedtransport address 192.0.2.3:32766 in order to begin establishing e.g.VoIP communications.

In accordance with the invention, from now on the relayed transportaddress 192.0.2.3:32766 allocated in steps 201-204 will actually be setup as an address for the virtual network interface of the invention.That is, socket calls from the applications 1110, 1120, 1130 to therelayed transport address 192.0.2.3:32766 will be intercepted andreplaced with appropriate protocol messages, as detailed below.

At step 206, the first application 1110 makes a socket call send( ) tothe bound socket containing data related to VoIP communications to beestablished with the first peer application 1321. For example, thecontained data may be a VoIP request message addressed to the first peerapplication 1321 (a VoIP application, as described above) at the aboveaddress 192.0.2.17:12734.

At step 207, the socket call send( ) is intercepted by the virtualnetwork interface 1140 of the invention. At step 208, the socket callsend( ) is replaced with a TURN protocol message ‘Send Indication’. Thatis, a ‘Send Indication’ message is created containing the data (the VoIPrequest message in the present example) originally contained in thesocket call send( ). At step 209, the ‘Send Indication’ is forwarded tothe TURN server 1310 via the network address translator 1200 which againreplaces the source address 10.0.1.1:4334 and creates a mapping from192.0.2.1:63346 to 10.0.1.1:4334, as above, steps 209-210.

The TURN server 1310 extracts data—i.e. the VoIP request message in thepresent example—contained in the received ‘Send Indication’ message, andforwards the extracted VoIP request message to the first peerapplication 1321 at 192.0.2.17:12734, step 211.

The first peer application 1321 sends a VoIP response message to thesource address 192.0.2.3:32766 of the received VoIP request message,i.e. to the relayed transport address at the TURN server 1310. The TURNserver 1310 encapsulates the received VoIP response message in a TURNprotocol message ‘Data Indication’ and sends it to destination address192.0.2.1:63346 (i.e. the network address translator 1200) with theoriginal source address 192.0.2.17:12734 contained in the ‘DataIndication’ message, step 213.

The network address translator 1200 forwards the ‘Data Indication’message towards the first application 1110 at address 10.0.1.1:4334based on the mapping the network address translator 1200 createdearlier, step 214. At step 215, the ‘Data Indication’ message isintercepted by the virtual network interface 1140 of the invention. Atstep 216, the virtual network interface 1140 analyzes the intercepted‘Data Indication’ message and determines that it contains a VoIPresponse message addressed from 192.0.2.17:12734 to 10.0.1.1:4334. Basedon this analysis, the virtual network interface 1140 forwards the VoIPresponse message to the earlier bound socket. As a result, the VoIPresponse message reaches the first application 1110. From the point ofview of the first application 1110, this request-response communicationwas executed with socket operations. In other words, no STUN/TURN clientfunctionalities need to be implemented in applications 1110, 1120, 1130.

In addition to utilizing various TURN protocol messages, such as SetActive Destination, Data Indication, and Send Indication in deliveringapplication data, as described above, TURN protocol channel allocationsmay also be utilized, as appropriate.

The exemplary embodiments can include, for example, any suitableservers, workstations, PCs, laptop computers, PDAs, Internet appliances,handheld devices, cellular telephones, wireless devices, other devices,and the like, capable of performing the processes of the exemplaryembodiments. The devices and subsystems of the exemplary embodiments cancommunicate with each other using any suitable protocol and can beimplemented using one or more programmed computer systems or devices.

One or more interface mechanisms can be used with the exemplaryembodiments, including, for example, Internet access, telecommunicationsin any suitable form (e.g., voice, modem, and the like), wirelesscommunications media, and the like. For example, employed communicationsnetworks or links can include one or more wireless communicationsnetworks, cellular communications networks, 3 G communications networks,Public Switched Telephone Network (PSTNs), Packet Data Networks (PDNs),the Internet, intranets, a combination thereof, and the like.

It is to be understood that the exemplary embodiments are for exemplarypurposes, as many variations of the specific hardware used to implementthe exemplary embodiments are possible, as will be appreciated by thoseskilled in the hardware and/or software art(s). For example, thefunctionality of one or more of the components of the exemplaryembodiments can be implemented via one or more hardware and/or softwaredevices.

The exemplary embodiments can store information relating to variousprocesses described herein. This information can be stored in one ormore memories, such as a hard disk, optical disk, magneto-optical disk,RAM, and the like. One or more databases can store the information usedto implement the exemplary embodiments of the present inventions. Thedatabases can be organized using data structures (e.g., records, tables,arrays, fields, graphs, trees, lists, and the like) included in one ormore memories or storage devices listed herein. The processes describedwith respect to the exemplary embodiments can include appropriate datastructures for storing data collected and/or generated by the processesof the devices and subsystems of the exemplary embodiments in one ormore databases.

All or a portion of the exemplary embodiments can be convenientlyimplemented using one or more general purpose processors,microprocessors, digital signal processors, micro-controllers, and thelike, programmed according to the teachings of the exemplary embodimentsof the present inventions, as will be appreciated by those skilled inthe computer and/or software art(s). Appropriate software can be readilyprepared by programmers of ordinary skill based on the teachings of theexemplary embodiments, as will be appreciated by those skilled in thesoftware art. Further, the exemplary embodiments can be implemented onthe World Wide Web. In addition, the exemplary embodiments can beimplemented by the preparation of application-specific integratedcircuits or by interconnecting an appropriate network of conventionalcomponent circuits, as will be appreciated by those skilled in theelectrical art(s). Thus, the exemplary embodiments are not limited toany specific combination of hardware and/or software.

Stored on any one or on a combination of computer readable media, theexemplary embodiments of the present inventions can include software forcontrolling the components of the exemplary embodiments, for driving thecomponents of the exemplary embodiments, for enabling the components ofthe exemplary embodiments to interact with a human user, and the like.

Such software can include, but is not limited to, device drivers,firmware, operating systems, development tools, applications software,and the like. Such computer readable media further can include thecomputer program product of an embodiment of the present inventions forperforming all or a portion (if processing is distributed) of theprocessing performed in implementing the inventions. Computer codedevices of the exemplary embodiments of the present inventions caninclude any suitable interpretable or executable code mechanism,including but not limited to scripts, interpretable programs, dynamiclink libraries (DLLs), Java classes and applets, complete executableprograms, Common Object Request Broker Architecture (CORBA) objects, andthe like. Moreover, parts of the processing of the exemplary embodimentsof the present inventions can be distributed for better performance,reliability, cost, and the like.

As stated above, the components of the exemplary embodiments can includecomputer readable medium or memories for holding instructions programmedaccording to the teachings of the present inventions and for holdingdata structures, tables, records, and/or other data described herein.Computer readable medium can include any suitable medium thatparticipates in providing instructions to a processor for execution.Such a medium can take many forms, including but not limited to,non-volatile media, volatile media, trans-mission media, and the like.Non-volatile media can include, for example, optical or magnetic disks,magneto-optical disks, and the like. Volatile media can include dynamicmemories, and the like. Transmission media can include coaxial cables,copper wire, fiber optics, and the like. Transmission media also cantake the form of acoustic, optical, electromagnetic waves, and the like,such as those generated during radio frequency (RF) communications,infrared (IR) data communications, and the like. Common forms ofcomputer-readable media can include, for example, a floppy disk, aflexible disk, hard disk, magnetic tape, any other suitable magneticmedium, a CD-ROM, CD-R, CD-RW, DVD, DVD-R, DVD+R, DVD-RW, DVD+RW,DVD-RAM, HD-DVD, Blu-ray Disc, any other suitable optical medium, punchcards, paper tape, optical mark sheets, any other suitable physicalmedium with patterns of holes or other optically recognizable indicia, aRAM, a PROM, an EPROM, a FLASH-EPROM, any other suitable memory chip orcartridge, a carrier wave or any other suitable medium from which acomputer can read.

While the present inventions have been described in connection with anumber of exemplary embodiments, and implementations, the presentinventions are not so limited, but rather cover various modifications,and equivalent arrangements, which fall within the purview ofprospective claims.

1-25. (canceled)
 26. A method, comprising: in response to at least onesocket being bound to a relayed transport address by at least oneapplication, intercepting socket calls made by the at least oneapplication to the bound socket, replacing each intercepted socket callwith a predetermined network address translator traversal protocolmessage, and forwarding the network address translator traversalprotocol messages to a network address translator traversal server, therelayed transport address assigned by the network address translatortraversal server for data packet relay use by the at least oneapplication behind the network address translator; and in response to atleast one network address translator traversal protocol message beingsent from the network address translator traversal server to the atleast one application, intercepting the sent at least one networkaddress translator traversal protocol message, analyzing data in theintercepted at least one network address translator traversal protocolmessage, and forwarding the data to the at least one socket bound to therelayed transport address based on the analysis.
 27. The methodaccording to claim 26, wherein the network address translator traversalprotocol comprises a session traversal utilities for network addresstranslation protocol provided with traversal using relays around networkaddress translation extension.
 28. The method according to claim 27,wherein at least one intercepted socket call comprises a socket callconnect, and wherein the replacing predetermined network addresstranslator traversal protocol message comprises a connect requestmessage.
 29. The method according to claim 27, wherein at least oneintercepted socket call comprises a socket call connect, and wherein thereplacing predetermined network address translator traversal protocolmessage comprises a set active destination request message.
 30. Themethod according to claim 27, wherein at least one intercepted socketcall comprises a socket call send, and wherein the replacingpredetermined network address translator traversal protocol messagecomprises a send indication message.
 31. The method according to claim27, wherein at least one intercepted socket call comprises a socket callreceive, and wherein the replacing predetermined network addresstranslator traversal protocol message comprises a data indicationmessage.
 32. The method according to claim 26, wherein the at least onesocket bound to the relayed transport address comprises one of adatagram socket and a stream socket.
 33. The method according to claim26, wherein the assigned relayed transport address comprises multipleports, each for binding to one socket.
 34. An apparatus, comprising: afirst interceptor configured to intercept, in response to at least onesocket being bound to a relayed transport address by at least oneapplication behind a network address translator, socket calls made bythe at least one application to the bound socket, replace eachintercepted socket call with a predetermined network address translatortraversal protocol message, and forward the network address translatortraversal protocol messages to a network address translator traversalserver, the relayed transport address assigned by the network addresstranslator traversal server for data packet relay use by the at leastone application behind the network address translator; and a secondinterceptor configured to, in response to at least one network addresstranslator traversal protocol message being sent from the networkaddress translator traversal server to the at least one application,intercept the sent at least one network address translator traversalprotocol message, analyze data in the intercepted at least one networkaddress translator traversal protocol message, and forward the data tothe at least one socket bound to the relayed transport address based onthe analysis.
 35. The apparatus according to claim 34, wherein thenetwork address translator traversal protocol comprises a sessiontraversal utilities for network address translation protocol providedwith traversal using relays around network address translationextension.
 36. The apparatus according to claim 35, wherein at least oneintercepted socket call comprises a socket call connect, and wherein thereplacing predetermined network address translator traversal protocolmessage comprises a connect request message.
 37. The apparatus accordingto claim 35, wherein at least one intercepted socket call comprises asocket call connect, and wherein the replacing predetermined networkaddress translator traversal protocol message comprises a set activedestination request message.
 38. The apparatus according to claim 35,wherein at least one intercepted socket call comprises a socket callsend, and wherein the replacing predetermined network address translatortraversal protocol message comprises a send indication message.
 39. Theapparatus according to claim 35, wherein at least one intercepted socketcall comprises a socket call receive, and wherein the replacingpredetermined network address translator traversal protocol messagecomprises a data indication message.
 40. The apparatus according toclaim 34, wherein the at least one socket bound to the relayed transportaddress comprises one of a datagram socket and a stream socket.
 41. Theapparatus according to claim 34, wherein the assigned relayed transportaddress comprises multiple ports, each for binding to one socket.
 42. Acomputer program embodied on a computer readable medium, the computerprogram controlling a data-processing device to perform: in response toat least one socket being bound to a relayed transport address by atleast one application, intercepting socket calls made by the at leastone application to the bound socket, replacing each intercepted socketcall with a predetermined network address translator traversal protocolmessage, and forwarding the network address translator traversalprotocol messages to a network address translator traversal server, therelayed transport address assigned by the network address translatortraversal server for data packet relay use by the at least oneapplication behind the network address translator; and in response to atleast one network address translator traversal protocol message beingsent from the network address translator traversal server to the atleast one application, intercepting the sent at least one networkaddress translator traversal protocol message, analyzing data in theintercepted at least one network address translator traversal protocolmessage, and forwarding the data to the at least one socket bound to therelayed transport address based on the analysis.